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(54) System and method of electronic mail fiftering 



(57) A modular system and method for filtering 
electronic mail messages is described. A message is 
received and processed through a one or more filter flows. 
Each filter flow includes one or more self-contained nodes 
which can be interconnected in whatever order is required 
to enforce a given security policy. The available nodes 
include filters,, modifiers or terminals. Node independence 
provides a policy- neutral environment for constructing 
filter flows* and components are easily rearranged to 
change policy. A filter flow may be as simple as 
forwarding the mail to the intended recipient or may 
perform one or more checks where it decides whether to 
forward, reject, ram (or some connbinatlon thereof) the 
message. Certain node types are also able to append 
information on to a mail message, while others are able to 
modify certain pans of a mail message.. Certain node 
types are able to generate audit or log messages in 
concert with processing a mail message. A graphical user 
interface creates and maintains the filter flows. Figs. 8A, 
SB, (not shown). 
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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 
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1/12. 

begin rules 

# 
# 

# This defines a filter policy for e-mail sent from the source network 

# to the destination network. The networks are named using values 

# from burb.conf. There may only be one entry for any source/ 

# destination pair. The map name is a name of a filter map that is 

# built using the administration tool. 
# 

filter_flow(source_network dest_network map_name) ~ 10 
end_rules 
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910- filter: Key Word | Binary | Random | Size 

920- terminal: Audit | Deliver | LogToFile | RetumToSender | MailToReviewer 
930-- "^o*^''^^^* GenericRejectReason 

id: { user entered identifier } 

user_filter_id: id 

user_modifier_id: id 

user_terminal_id: id 

conf_info: conf_path confjoken 

conf terminal: terminal conf_info userjerminaljd 

conf_modifier:modifier confjnfo user modifierjd 

conf_filter: filter confjnfo user_filterjd 

configured_object: confjerminal | conf_modifier | conf_filter 

drain^list: { list of one or more drains } 

pass_drain_list: drainjist 

reject_drain_list: drain_list 

drain_id: id 

drain tenninal : user_tenninal_id drain Jd 

drain_modifier: user^modifierjd pass^drain_list drainjd 

drain^filter: user_filterjd pass_drainjist reject_drainjist drain_id 

drain: drainjemiinai j drain_modifier | drain_filter 

burb: { valid burb name or number } 

source_burb: burb 

dest_burb: burb 

flow: source_burb desi_burb (drain_id | user_terminal_id ) 
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SYSTEM AND METHOD OF ELECTRONIC MAIL FILTERING 

5 A portion of the disclosure of this patent documcDt contains material 

which is subject to copyright protection. The copyright owner has no objection 
to the facsimile reproduction by any one of the patent disclosure, as it appears in 
the Patent and Trademark OfiScc patent files or records, but otherwise reserves 
all copyright rights whatsoever. 

1 0 Background of the Invention 

Field of the Invention 

The present invention relates to computer securiiy, and more 
particularly, to an apparatus and method for managing electronic mail message 
processing. 

15 Background infQntiatiQp 

Electronic mail is becoming a more integral means of 
communication for everything from smdents exchanging messages with each 
other and their teachers to highly sensitive business and governmental 
communications. Communication technology has expanded to where anyone 

20 with a personal computer, minimal software and a modem can connc(;t to the 
Internet and send mail to any other computer, ^^^lether it is across the street or 
around the world. Because anyone can send mail to anyone else, many sites 
have begun establishing security policies which specify how mail sent to and 
received from external locations should be handled. These sites use mail; 

25 messsaging systems to analyze incoming and outgoing messages and determine ' 
whether information concerning the message should be recorded or reviewed, or 
whether the message should be allowed to be delivered at all. 

Every customer has different needs. Commercial security policy 
different for different business types and installations, and different from 

30 government and educational institution needs. To date, however, conventional 
systems have implicit assumptions about the security to be enforced built in, 
based on the rules of the security policy to be enforced. Thus, where a site is big 



2 



enough to have departments with different needs, or where one filter is being 
developed for a number of clients, either a separate system must be developed 
and installed for each site/department, or the system must be written to enforce 
the lowest common denominator of the rules specified by each site/depaitment 
S In addition, systems constructed to dale often require an 

independent computer system located such that all mail passing between external 
and internal locations passes through the filter system. Such systans ^ically 
are limited to looking for a specified set of keywords, making processing 
decisions based on whether the keyword is present or missing, dcperuiing on the 
10 rule. 

Finally, conventional systems provided to date are only capable 
of a yes/no decision, providing only one option at each decision point The 
message (or response to the message) must go down only one path - forwarded 
to the destination, returned to the source, or rerouted to a different destinatioa 
1 5 What is needed is fiinctionaliQr 5iq)porting multiple addresses for a single 
message. It is therefore difficult to implement a policy o^ for example, 
forwarding quesdonable messages on to their original destination but also 
forwarding a copy to an internal auditor or logging system. ConveatioQal 
systems cannot siq)port this requirement 
20 Whatisiieededisaway of structuring an electronic mail 

messaging system that is flexible enough to implement a variety of security 
polides but which is also simple for a network adniiiustrator to configure. Such 
a system would preferably provide mtdtiplc routing paths form each decision 
point 

25 Summary of the Invention 

The present invention is a system and mediod for filtering electronic 
mail messages. A message is received and processed through a one or more filter 
flows. Each filter flow includes one or more self-contained nodes which can be 
combined in whatever order is required to enforce a given security policy. Node 
30 independence provides a policy-neiitral environment for constmcting filler flE*^^ A 
filter flow may be as simple as forwarding the mail to the intended recipient, or may 
pcrfonn one or more checks where it decides whctiicr to forward, reject, remm (or 
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some combination hereof) the message. Certain node types arc also able to append 
information on to a mail message, while others arc able to modify certain parts of a 
mail message. Certain node types arc able to generate audit or log messages in concert 
with processing a mail message. 
5 The result is a generalized, modular system for building mail 

filter flows. The filter system of the present invention is policy neutral - any one 
flow enforcing a particular security policy is constructed where necessary. The 
same components can be rcanangcd to enforce a different policy without 
reprogamming any of the individual modules. 
1 0 According to one aspect of the present mvention, electronic mail 

messages are filtered by receiving a message, analyzing wbeiiiicr it meets the 
filter criteria, and forwarding the message to the filter if it meets 4e filter 
criteria. The message is delivered if it does not meet flie criteria. 

According to another aspect of (he present invention, the filler 
1 5 analyzes the electronic mail message, and based on its characteristics ei&er 
delivers or rejects the message. In addition, the filter may generate an audit 
message in conjunction with the results of ihe analysis. 

According to another aspect of the preset invention, an 
electronic maU filter includes an analysis module for analyzing the mail message 
20 using one or more individual filter nodes and an output module for generating a 
plurality of output messages based on the analysis of the analysis module. The 
available filter nodes include a filter, a modifier, or a terminal. The mail filter 
may also include a graphical user intcrftce for creating and maintaining the 
electronic mail filter. 
25 Brief Description of the Drawings 

Figure 1 shows one example of a flow configuratioiL 

Figure 2 is a block diagram showing one embodiment of a mail 
filler incorporated into a mail framewodL 

Figure 3 shows the main components of a mail filter node 
30 according to one embodiment ofthe present invention. 

Figure 4 is a graphical representation of an extensible data object 

tree. 
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Figure 5 shows a simple example of a terminal output module. 

Figure 6 shows aa escample of a filter module. 

Figure 7 shows an exan^le of how components may be wired 
together to create a filter flow in the mail framework of the present invention. 
5 Figure 8A is a representation of the mail filter map maintenance 

window presented by the user interface. 

Figure 8B is a representation of option windows presented by the 

user interface. 

Figure 9 presents an example of the specification of a filter flow 
10 using the flow language. 

Figure 1 0 is a graphic representation of sample flow rules. 
Figure 1 1 illustrates a filter map where there is a separate auditor 

for each filter. 

Figure 12 illustrates a filter map ^^ere two difiFerent filters use 
1 5 the same auditor. 

Figure 13 shows an embodiment wherein rejections from multiple 
filters are sent to the same auditor via a single terminal 

Figure 14 shows an instance where rejects are passed forward and 
audits go to a shared auditor. 
20 Figure 1 S shows an embodiment of a filter flow where separate 

auditors are used and rejects are passed forward. 

Figure 16 illustrates a map exBsnplc using the same auditor and 
passing rejects forward. 

Figure 1 7 shows a filter map combining the ideas presented in 

25 Figures 11-16. 

Figure 18 shows an example a convendonal method of attaching a 
rejection reason to messages. 

Figure 19 shows an example an expanded method of attaching a 
rejection reason to messages according to one embodiment of the present 
30 invention. 
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DetaUed Description of the Preferred Efflbodiments 

In the following Detailed Description of the Prefeiml 
Embodiments, reference is made to the accompanying Drawings which form a 
part hereof, and in which are shown by way of illustration specific embodiments 
in which the invention may be practiced. It is to be understood that other 
embodiments may be utilized and structural changes may be made without 
departing from the scope of the present invention. 

There are two aspects of mail filtering. Firstis what to filter, the 
second how to filter it. The first question is answered by one embodiment of the 
present invention in the "mail fihcr policy" file. This simply lists "butb" pairs 
which should be filtered. A burb refers to one protocol stack in an environment 
providing network separation by keeping separate protocol stacks or regions for 
each side of the system. A more detailed description of buibs is given in 
"System and Method for Achieving Network Separation*" by Gooderum et al. 
(PCT Published Application No. WO 97/29413, published on August 14, 1997), 
the description of which is hereby incorporated by reference. Under network 
separation, a plurality of burbs or regions is defined. Each burb includes a 
protocol stack. Each of the plurality of network interftces is assigned to one of 
the plurality of buibs and more than one network inter&ce can be assigned to a 
particular burb. Processes are bound to specific burbs when they try to access 
that burb's protocol stack aiul communication between processes &<isigned to 
different burbs is restricted. Routing to a given stack may be limited to being 
done at the very top or bottom of the dataflow so that a given packet^ piece of 
data, control message, etc. is bound to a particular stack at creation. 

The mail filter policy file is us^ by a mail delivery agent to 
determine whether to pass mail on to the next buxb or to drop it into a queue. 
Listed burb pairs arc filtered and unlisted pain are relayed to the destination 
burb. This file is read by die a mail queuing program for each delivery, so it is 
kept deliberately minimal to reduce overhead. The filter policy is de:cribed in 
greater detail below. 
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The second question, how to filter mail messages, is relevant to 
the programs which run the mail queues. These are long running daemons, so it 
is not a problem if they have some additional startup overhead. Filter 
configuration is also discussed in greater detail below. 
5 The flow configuration is in a file and comprises a simple listing 

of bxirb pairs and a map name. This is configurable by the mail administrator 
and the system administrator under the operational kernel. This file must exist at 
installation time and be added if a system is upgraded. Initially no flows will be 
listed, but may be added at any time by the administrator. If the file is missing, 

1 0 the Tpail queue program will not deliver mail and will return an error to the 
sendmail application that invoked it The convention for keeping read-only 
skeleton files around should be adhered to for 4is file. An example of a flow 
configuration is shown in Figure 1, viere each filter flow line 10 maps a burb- 
pair to a map name 1 2. 

1 5 In one embodiment, the filter parent daemon is a tiny program 

that creates a pid/lock file and then executes filter queue runner programs. 
Whenever one of the top level configuration files is altered, this process should 
be signaled. It will then signal or restart its children as appropriate. 

A program responsible for queuing mail will be a run by sendmaU 

20 with source and destination burb parameters on the command line. The queuing 
agent will be a gate executable. Its cflFccdve domain (mque) will permit it to 
write the file into the queue directory. By being a gate, it will be able to check 
the real domain, which will be that of the parent sendmail process. It will check 
that the source burb parameter matches the sendmail sotirce burb. If they 

25 disagree, then there is a configuration error or sendmail has been subverted. In 
either case the queue agent will audit and exit If there are no startup problems, 
the queue agent will receive the message via SMTP over stdin/stdout. SMTP 
support will be the minimal necessary to receive the message from a properly 
configured sendmail process on the local system. 

30 A long*ruiming daemon is responsible for processing the mail for 

a given flow. The daemon is controlled by the filter parent It does not read the 
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policy file, but rather just looks at its command line for the burbs to use (for 
sender and recipient), the map file to use, and the queue directory in which to 
function. In one embodiment, the command line is fonnatted in the following 
manner. 

5 

/usr/libex8c/mfil_queue„runner<src.burt» <dest.barb> <qu6iM_dif> <mapjle> [-d "highjlow/] 

Filter configuration needs to be as flexible as possible so as to 
allow future growth. This is good, however, because filter configuration can 

1 0 become one of those features with many fiaccts that arc visual and easy for non- 
technical people to understand. Filter administration starts with a configuration 
file which identifies filter components, how they arc chained together, and where 
the configuration information for each instance is located. Components mclude 
terminal output modules, data modifiers and filtering modules. 

1 5 The electronic mail system, or 'Inail framework**, k a collection 

of independent objects or 'Codes'' which can be arranged into one or more filter 
flows (or filters) to describe/enforce any security policy. Figure 2 is a block 
diagram showing one embodiment of such a filter 220 incoiporated into mail 
framework 200. Filter 220 can be expressed as an tntercomiected series of 

20 nodes. In one embodiment, there are three general node types: a filter, a 

modifier, and a terminal. The node types art described in greater detail below. 
Each node in filter 220 comprises three components: initialization, message 
processing, and node clean-up. According to one embodiment, shown in Figure 
3, each node is composed of three basic sections 3 10, 320, 330 v4iich all exist . 

25 within the same process. Each section provides a distinct set of fimctions. 

Initialization module 310 provides the initialization functions, including loading 
a configuration file which contains any configurable settings fi>r the node. 
Examples of various configuration files are presented later in the discussion of 
each node type. Message analysis module 320 provides the operational 

30 functions of the node. These fiinctions may include receiving the mcjsagc, 
applying the filtering algorithm to the message, and preparing and transmitting 
the results of the node's processing. Clean-up module 330 comprises functions 
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viiiich clean up and shut down the node when it ceases processing. These 
functions ensure that the system within which the node is executing is left in a 
good state. This provides a well-defined boundary between any two nodes, 
ensuring maximum security. 
5 Mail framework 200 is intended to support the development of a 

xnix-and-match set of filters which can be chained together according to the 
whim of the administrator. At the same time, die data structures must be flexible 
and expressive so that sophisticated filters may be constructed. In one 
embodiment, the implementation is fimher constrained, using C rather than a 
1 0 more expressive language like C-H- or Sather, in order to achieve greater 

processing speed. The extensible data structure (edo) shown in Figure 4 is an 
attempt to create such a data structure. The edo essentially creates a shallow 
class hierarchy with a common base class and simple up/down casting. 

An edo is a standardized simple data stmcture with certain 
1 5 guaranteed features ^xiuch can be expanded upon for application-specific uses. 
A base set of edos are always available and are suitable for simple text or byte 
data filters. More sophisticated filters may be constructed to use specialized 
edos with extra application-specific information. 

The type edo-t is, conceptually, an abstract base class. It provides 
20 the common interface to all of the edo data structures. Figure 4 shows the 
conceptual class hierarchy. The first field of the edo base 410, embodying the 
cdo_t type, is an enumerated integer value indicating the data type. All edos 
must have the same three fields at the start of the structure. Thi^ group of fields 
may be partially interpreted as a bit mask. Bit one is compatible with edo-bytes, 
25 and is set if it is a '*byte bucket'*. The bit mask interpretation is not entirely 

consistent with respect to casting, due to fhe limitations of trying to do this in the 
C programming language. The second field of the edo base is a state field v^4iich 
is filled in by the filtering fimctions. The state field indicates whether the edo 
has been rejected by a previous filter. Other bits indicate if the edo was deemed 
30 suspicious or if it was edited by a filter. Neither the suspicious or edited states 
are exclusive of the bucket being considered 'okay* or 'rejected'. A bit mask can 
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be used to pull out the pieces considered importani for filter or modifier node 
processing. Filler and modifier nodes may ignore the state field or skip 
processing rejected data nodes, depending on their purpose. The iliird field of 
any edo node is a pointer to a "copy constructor^. This is a function that can 
5 duplicate the node, given a pointer to itself. The forth field is a pointer to a 
"destructor" function which can delete the node and ftec up all dynamically 
allocated memory. Convenience macros arc provided for calling tliese member 
functions. As an example, for a given edo *c', these would be invoked as: 

copy_edo(e); 

10 and 

delete.edo (e); 

The bytes edo 420 section is a simple Tjuckei of bytes" suitable 
for many filtering operations. It is a dynamically allocated array of bytes which 

1 5 may be searched and added to by filter or modifier nodes. This is where the 
actual message is located. A filta or modifier node which alters the data is 
permitted to use standard system calls (such as 'icailocQ*) to resize bytes edo 
array 420 if needed. 

The data edo 430 section is a metadata section which allows 

20 annotation and additional data to be added to the original message. It is a byte 
bucket with a collection of edos ^ch may be searched and added to by filter or 
modifier nodes. Data edo 430 is derived from a bytes edo 420, and contains the 
atmotations appended by the filter or modifier nodes. Such annotations i^ay 
include information which carries parsed data (which, for example, identifies the' 

25 message sender or recipient), or perhaps the rejection reason if the message 
failed a filter. Filter or modifier nodes knowledgeable of the various types of 
optional data (which are also represented as edos) may draw on this knowledge 
for addidonal context. Simpler filters can ignore the collection and may even 
process an data edo section 430 as a bytes edo section 420, which is efifectively 

30 its base class. 

The network edo 450 is a data EDO with some additional context 
describing the data which is bebg operated on by the filter or modifier node. It 
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includes the source and destination address of the data. Both, one, or neither of 
the addresses may be an address of the machine on which the mail ftamework 
resides, depending on where the client and server processes arc located. This 
information is obtained from the socket which was the source of the data 
5 (getpeemameQ, getsocknameQ). Indexes for other physical and logical portions 
are also included with the address. Use of the e)Ctra inforaiation in networic edo 
4S0 may provide for better filtering, but not all data sources will be associated 
with a network. In addition, electronic mail filtering may be also done on files 
rather than on network connections. 
1 0 The collection EDO 440 is derived from ±c base EDO 4 1 0. to 

which it adds pointers to three additional fimctions. These functions provide a 
simple random access data structure for storing edo pointers and indexing them 
by keyword. One function vnll add an (edo, keyword) pair (tuple) to the 
collection. Keywords must be unique within a collection. The second fimction 
1 5 will find an edo in the collection based on the keyword, and the third fimction 
will trmove an edo from the collection, based an the keyword. An edo 
collection is used as a field in the data and network edo types 430, 450. The 
anticipated use of the edo collection 440 is as a means for carrying a set of 
annotations along with the data portion of a message. For example, one filter 
20 might parse out the headers from an electronic mail message. Other filters could 
then look up the headers in the annotation and could grade the headers without 
being smait enough to parse them fix>m the rest of the message. This supports 
tising filter sequences for a stream processing-based programming paradigm. 

The binary filter expects fte entire content of the message to be 
25 contained within the Bytes 410 sccdon of the EDO 400. The actual binary filter 
is called once for each EDO Bytes section 410. The entire contents of the Bytes 
section 410 is treated as a single message by the binaiy filter. This approach 
cannot guarantee that any specific e-mail message will be caught, but will, 
however, catch the widest variety of violators with a single algorithm^ This 
30 generalized approach improves over conventional systems in other aspects as 
well. Since the binary filter approach is not format-specific it is much more 
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diflficult to break. Format-specific systems follow the rules of the fonnal and 
thus h is much easier to avoid detection by imitating the fonnat In addition, file 
formats not previously encountered are still likely to be detected in a binary filter 
system. 

5 The programming interface also identifies the range of node 

behaviors. In one embodiment, it is the programming inter&cev/hich enforces 
the one input, one/two output rule followed by every filter node. This rule b 
strictly enforced in order to maintain the rigor of the system. Such an approach 
docs not, however, limit the functionality of the system appreciably. If a more 
1 0 complex decision tree is required to enforce a particular rule, the tree can be 
constructed by chaining a series of modules. This is preferable over building 
complex nodes for two reasons. One is because the individual nodes retain their 
independence and remain policy-neutral. The other is because the flow is easier 
to maintain and modify in the case of future policy changes. It is the 

1 5 programming interface which also supports the feature that any one ou^ut can 
be directed to one or more inputs. The programming interfice is implemented in 
the C-H- programming language, but the filter nodes can be implemented in C. 
The edo data structure described above enables the flexibility in die filter nodes 
which would otherwise be unavailable in a procedure written in C. 

20 All of the nodes allow additional intetacdons with applications 

emnal to the mail system for other than rnail processing functions. For 
example, a filter node may read initialization data from an external file, or write 
a message to a log or audit file. The input/output limitations imposed by the 
programming interface apply only to the direct interactions between filter nodes. 

25 Mail Filter nodes are made operational in one of three ways. In 

one embodimenz, the nodes are all compiled into a single library. In this 
embodiment when an node is called the subroudne in the library is executed. 
This is the best-perfonning form. However, it creates some security issues 
because all of the nodes are in the same library. To belter secure dif mail filter 

30 system the nodes can each be compiled individually. This form loses some 
performance speed, because each filter node module is brought into memory 
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when it is called, rather than having all of them in memory after the system is 
initialize. However, separation is maximized, providing the best protection 
against being able to attack one module via a less-protected module. The Aird 
embodiment is a compromise between the two previously described In this 
5 embodiment a shell for each filler node is compiled into a common library, but 
instead of the library subroutine executing the filter module code, it calls an 
extcmai program. This gives back some of the speed lost when the modules are 
completely independent, without completely sacrificing the concei»t of isolating 
the modules. 

1 0 The mail filter framework of the present invention does not 

completely handle mail in different fomiats. The same programming interface 
code can be used for the structure underlying fiber flows for different formats. 
In another embodiment, a common mail filter system may be used as a 
preprocessing step to enable common processing. In this embodiment the filter 

15 flow(s) are used to identify which part of the message to use, and/or to direct the 
message to the proper application for further processing. This limitation is 
acceptable, because it is desirable to stay wiA a configurable signal which can be 
universally used. If 4e signal is made aware of a specific protocol (for example, 
SMTP, X.400, etc.), the mail filter system is implicitly unable to process other 

20 protocols. 

Filtering modules accept one input and generate two outputs. 
One output is the input edo, possibly with modifications. This output is directed 
to the next module based on the edo's filter-filter result field. A filtering module 
is visualized as having two outputs, one for PASSed edos and one for 

25 REJECTcd edos, each of which may be separately routed to other components. 
Figure 5 shows an example of a terminal ouqnit module 500 and Figure 6 shows 
an example of a filtering module 600. A filter node accepts the inpxit as 
representing a complete entity. Filler components may be combined to form a 
compound object, vAixch may then be used as a filter module or a tciminal output 

30 module. 
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The configuration file is meant to be vciy flexible and extensible. 
TTie queue runner programs should be able to accommodate this. It is desirable, 
but not required to make this flexibUity available to the user. Figui e 7 shows an 
example of how components may be wired togelher to create a filter flow in the 
mail framework of the present invention. The graphical user interface (GUI) 
should take inspiration from programs like LabVicw*, Khoros*, IRIS* 
Explorer", AVS* and the like. Examples of these products arc available on the 
Internet at the following URLs; 

Khoros screen shot htlp: /Mww. Wwfos. untn. eduflchoros/screen. jpg 

general information on Khoros: http:/A*rww.lchoros.unm.edufthon)srtchoros2rtiome.html 
AVS screen shot htlp: //**w.avs.com/producte/rem_sense2. gif 

generallnfbrmationonAVS: htlp: //*ww. avs. com; 



15 Another embodiment of the present invention comprises a | 

interface for constructing and maintaining maU flows within the mail framework. 
Figure 8A is a representation of one embodiment of the flow editii»g screen 800. 
The flow editing screen includes a pick list of the node types (connector 801, 
terminal 802, modifier 803. and filter 804) avaflable to include in the filter flows. 

20 and a window or "canvas" 805 for graphically constructing each filter flow. The 
administrator selects one or more filternodes 802-804 and locates them on 
canvas 805 m the order in which messages are to be processed. The nodes are 

then connected using the connector icon 801 to show the channels 841. 843, 845, 
847, 849 for the input and ou^ut(s) for each node. An additional menu window 

25 . shown in Figure 8B, provides, for example, a window for defining and 
maintaining individual nodes 860 and filter maps 862. Each node is given a 
unique name, and its characteristics (such as how it processed each input 
message) axe defined or modified using dicse menus and windows 801. 

References in the description of the mail framework of the present 

30 invention imply assumptions about how the information will be displayed and 
manipulated. These are not to be interpreted as rcqmremcnts, but rather as a 
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reflection of one cmbodinient of how maU framework is implemented and of the 

associated interfaces. ? 

A filter flow is build up in a simple language. It consists of 
simple object types, configurations of those types, aggregate objects and objects 
5 that form associations between other objects. In the actual implementation this 
is all represented in a configuration file, but at this point it will be described at a 

more abstract level. 

Some of the objects (or tiicir identifiers) described here will be 
directly visible and manipulated by the administrator through the (rUI. Other 
1 0 objects which are less directly visible are manipulated via a graphical metaphor 
and are created and destroyed on the fly by the GUI. as needed, to organize the 
objects. The visual program that is built up out of 4ese objects may be referred 
to as a map, 

All visible objects in a GUI map editor arc "drains ". Drain 
1 5 objects, and their identifiers, are created dynamically (except configured 

terminals, vAich can be used as-is) when the user selects a configured object and 
drags it onto 4e canvas. As the system eiqjands. there wiD be more kinds of 
filters, modifiers and terminals, but the underlying logical structure should not 
change. The GUI is designed such fliat it can be expanded to support 
20 configuring instances of new primitives, but will it will siqjport programming the 
new primitives into a new map without any changes. 

Figure 9 presents an example of die specification of a filter flow 
using the flow language. The specification includes such information as tfie 
available node types 910, 920, 930. In practice a filter flow specification is 
25 written with syntax consistent with the configuration file formats used by the 
system upon vWch the mail stmcture is operating. Tabic 1. below, shows the 
sample flow rules graphically presented in Figure 10. 
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Table 1: Sample Flow Rules 
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drain Jist(H) 
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oacf^tenminaLW 
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driin.fater(user^fitterjd, [C], [C.GD 
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drain.filtef (userJller.W. pl. P.E,F1) 
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When trying to convert a graph into a symbolic representation, it 
is simplest to label all of the nodes and then work from the leaves up towards the 
root For example, to convert Figure 7 we would first label the figure, as in 
Figure 10. Note that node G 1 030 is really superfluous, and could be eliminated 

20 ifonc wanted to minimize the nodes. It is however, valid, and perhaps useful, to 
build the map up through layers. A message comes into node A 101 Orchis a 
filter, If the message passes the fiher it is forwarded on to node B 1 0 1 5, which is 
also a filter. If the message fails node A 1010, an audit is forwarded to terminals 
D 1025, E 1040, and F 1045. If the message passes node B 1015 it is forwarded 

25 on to node C 1020, which is a terminal in this example. If the message fails 
filter B 1015. however, it is still forwarded to node C 1020. In addition, an audit 
is also forwarded to node G 1030, which in one embodiment is simply a 
terminal In another embodiment node G 1030 is acnially another filter flow. 
The audit received by node G 1030 comes into node H 1032, which is a filter. If 

30 the information comprising the audit passes the filter then inform^on is forward 
to terminal node 1 1 03 1 , otherwise an audit is forwarded to filter node J 1 033. If 
the audit information passes that filter 1033, information is forwarded to terminal 
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node K 1034. Otherwise, an audit is fonvanled to tcrmiiia^ As this 

example shows, the various nodes can be combined to form filter flows of any 
level of complexity. The above examples arc offered for illustration and are not 
intended to be exclusive or limiting. 
5 For a given message, each terminal in a naap will only be 

activated once. This principle governs when audit messages arc combined into a 
composite rejection message and when multiple notifications get sent to the 
same destination. Failures and rejection reasons do not carry forward through 
filters. Figure 1 1 illustrates a filter map ^cre there is a separate auditor for 

1 0 each filter. For the map shown in Figure 1 1 rejections from the key word search 
filter 1 1 10 will be sent to Auditor A 1 140. Messages that pass the key word 
search filter 1 1 1 0 will go to the binary filter 1 120. Rejections from the binary 
filter 1 120 will be sent to Auditor B 1 150. Messages that pass the binary filter 
1 120 will be delivered 1130. 

1 5 Figure 12 illustrates a filter map ^cre two different filters use 

the same auditor. For the map in Figure 12 rejections from the key word search 
filter 1 1 1 0 will be sent to Auditor A 1 1 40.1 . Messages that pass the key word 
search filter 11 10 will go to the binary filter 1120. Rejections from the binary 
filter 1 120 will also be sent to Auditor A 1 140.2. Messages that pass the binary 

20 filler 1 120 will be delivered 1 130, Note that auditor A nodes 1 1 40.1 and 1 1402 
arc individual termmals which direct rejections to the same destination. Figure 
1 3 shows an embodiment wherein rejections from multiple filters 1 110, 1 120 are 
sent to the same auditor via a single terminal 1 140. For the map in Figure 13 
rejections from the key word search filter 1 1 10 will be sent to Auditor A 1 140. 

25 Messages that pass the key word search filter 1110 will go to the binary filter 
1 1 20. Rejections from the binary filter 1 1 20 will also be sent to Auditor A 1 1 40. 
Messages that pass the binary filter 1 120 will be delivered 1 130. This 
effectively yields the same results as the map shown in Figure 12. It should be 
noted that in order to yield exactly the same results a message passing through 

30 fdter 1 1 20 would have to carry with it the rejection message generated by filter 
1110. 
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Figure 14 shows an instance where rejects arc passed forward and 
audits go to a shared auditor. According to the map in Figure 14 rejections from 
the key word search 1 1 10 and binary 1120 filters will be sent to Auditor A 1 140. 
All messages wiU go to the binary filter 1120, regardless of whether tbey pass or 
5 fail the key word search filter 1 1 10. If a message Ms the key word search filter 
1 1 10 and the binary filter J 120, then a single notification will be sent, and it will 
include the rejection reasons from boA filters. All messages wiU be delivered in 
this example. 

In the example filter flow shown in Figure 15. where separate 
1 0 auditors arc used and rejects arc passed forward, rejections from the key word 
search filter 1 1 10 will be sent to Auditor A 1 140. Rejections from Ae binary 
filter 1 1 20 will be sent to Auditor B 1 150. If a message foils the key word search 
filter 1 1 10 and the binary filler 1 120. two notifications will be sent The one 
sent to Auditor B 1 150 will only include the binary filter's 1 120 rejection reason. 
1 5 The one sent to Auditor A 1 1 40 will only include the key word search filtcr*s 
11 10 rejection reason. Amessagcmustpassthcbinary filter 1120 to be 
delivered, but delivery docs not depend on whether or not it passed the key word 
filter 11 10, 

Figure 16 illustrates a map example using di5)licatc auditors and 
20 passing rejects forward. For the map in 16 rejections from the key word search 
filter 1 1 10 will be sent to Auditor A 1 140.1. Rejections from the binary filter 
1 120 will also be sent to Auditor A 1 1402. If a message fails the key word 
search filter 1 1 10 and the binary filter 1 120, two separate notifications will be 
sent, each containing a single rejection reason. This is because there are separate 
25 tenninals for sending the notifications to Auditor A. A message must pass the 
binary filter 1 120 to be delivered, but delivery does not depend on whether or 
not it passed the key word filter 1110. 

The filter map shown in Figure 17 is just a combination of the 
ideas presented above. Auditor A 1 140 will only receive notificatipns for 
30 messages that foil the key word search filter 1110. Auditor B 1 150 will receive 
notifications for messages that fail the key word search filter 1 1 10, the binary 



I 
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filter 1 120, or both. If a message fails both. Auditor B 1 150 wUl receive a single 
notification that includes both rejection reasons. Auditor C 1 7 1 0 will only 
receive notifications for messages that fail -the binary search filter 1 120. Even if 
a message fails both, the notification that is sent to Auditor C 1710 will only 
5 include the binary filter's rejection reason. All messages will be delivered under 
this example. 

Filter configuration is acnially expressed by a simple language 
which is represented in the configuration file syntax of the system upon which 
the mail framework is executing. Appendix I contains an example of one 
10 embodiment of such a filter configuration file. The configuration is broken into 
three parts. The first part is the filter policy file described earlier. The second 
part is the filter configuration file which lists all of the parts which are used to 
assemble the filter policy diagrams (called maps). The configured parts and the 
file rules are described below. Finally, the Aird part is the map files. There is 
1 5 one map file per configured flow, as explained in more detail below. 

First, a brief description of the primitives employed in one 
embodiment of the present invention. The terminal modules list in the Terminal[ 
] entry are primitive objects that are listed so as to minimize the amount of 
knowledge diat.is hard-coded m the programming interfece. Following is an 
20 example of filter configuration rules. 
Filter Configuration Rules 
begin_rules 

25 conf Jnfb ( path token ) 

conrterminal ( terminal confJnteO conLid ) 

conCmodifier { modifier confJnfoO confjd) 

conf JIter { filter confJnfo() eonf_id ) 
end.rules 
30 Temiinall 1 

Modifier(] 

Rlter( ] 

35 

There may be only one Terminal[ ] entry in the configuration file. The modifier 
objects are listed in Modificr[ 1- These arc primitive objects and are listed so as 
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to minimize the amount of knowledge tbat is hard<odcd into the programming 
intcrfecc. TheremaybeonlyoneModificrdentryintheconfigurationfile. The 
third primitive is a filter. A filter list is a list of aU of the types of filters that the 
system knows about Putting the filter list in the configuration file lets the filter 
5 programming interface have as little hard-coded information as possible. As 
with the previously described primitives, there may be only one Filter[ ] entry in 

the configuration file. 

Configuration information for terminals, modifiers and filters are 
all specified in the same way using the "conf^info" rule. Iliis rule includes a 

10 path to a configuration file and a token. For simple items, the token alone may 
be sufficient For others, the file may include everything and the token may not 
be used. If multiple items share a configuration file, then the file may be 
specified by the path and the token may indicate a specific entry in the file. Ifa 
token or path field is unused it must be set to the string "none". This means that 

1 5 "none" cannot be used as a valid value for either of these fields. 

A configured terminal is given wifli die "confjerminal" rule. 
This associates an identifier with the terminal type and this set of configuration 
information. For many terminals there wiU be no configurables, so they may be 
pieconfiguied and the user will not be able to configure additional ones. The 

20 Terminal field must contain a valid field fiom the Tenninal[] list A configured 
modifier is given with the "conf-modifier" rule. This associates an identifier 
with the modifier type and this set of configuradon inforaiation. The Modifier 
field must contain a valid field from the Modifier[ ] list A configured filter is , 
given with the "configure filter" rule. Thb associates an identifier with the filter 

25 type and this set of configuration information. The Filter field must contain a 
valid field ftom die Filter[ ] list 

The"drain" objects are associations between a configured object 
and links to odier drain objects. These objects define die links in die flow 
diagrams. A configured terminal is also regarded as a drain objcci-jince it is 

30 complete in isolation due to die lack of outputs. For complex objects, ihe output 
fields are lists of drain id'.s. Configured objects have id's diat die user has 
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entered and uses to identify the object. Drains have identifiers also, but, except 
for configured terminals, these identifiers serve a purely internal ptirpose and 
may be chosen in vwhatever manner suits the administration tools. 

A drain list is a list of valid drain identifiers. This is simply an 

5 organizational object A drain modifier is an association of a configured 

modifier with a list of output drains. This association is given a drain identifier 
so that it can be linked to the output of an upstream node A drain filter is an 
association of a configured filter with a drain identifier (did). Hiis association is 
given a drain identifier so thai the drain filter can also be linked to the output of 

10 an upstream aode. Finally, for any flow there must be a single entry for that 
source/destination burb pair. This entry contains the burb names and a single 
drain identifier. By default (and probably in the skeleton file) all of the standard 
fiows should be configured to use the dcUver drain object. 

For each flow there is a configuration file that describes the flow. 

15 If a flow is in the poUcy file but there is no map. then maU wiU queue but not be 
processed. The map consists of associations of the configured filter objects 
shown in Figure 19. In one embodiment map files arc stored in a map 
subdirectory and are each individually named. For example, a map file may be 
named "kws_only.coar. In this case, the map name is "kws.only". Following 

20 are examples of a flow configuration file and a map configuration file. 
Flow Configuration File 

begin_rules 

« This associates the identifier of a configured terminal in filter.conf with a . 
25 # diain identifier (did). 
« 

drain_terminal( conf.id did) 

» This associates the identifier of a configured modifier in ^'^f-^^^^, l^Li, 
30 # ldenttt£(did). Outputfromlhemodifierwi!lbe8enttotheobjedslBtedbythe.r 

# did's in the passjdrainsQ GsL 



drain_modifier(conf_id pass_drainsl 1 did) 
35 # This associates the identifier of a configured modifier in filter.conf wrth a drain 
I - MessS'ei^'Ihat pass the fitter wiB be sent to the objects listed by their did's in the 

40 the 
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# reject_drains(llist 

drainJlter(confJd passjrains(] reject Jrains( 1 did) 

5 « This lists the drain identifier for the starting point for this map file. There may be 

# only one fiow() entry In the file. 
# 

flow (did) 
end.oiles 
10 # 

# This is a list of all of the drain identifiers (did's) that are valid in this file. 

# TheremaybeonlyonedrainJst(Ientiyinthefilfl. 
drainjistl J 

1 S Map Connguratlon File 

begin^fules 

" drain terrronal ( conf^id did ) 
dr3in"modlfier(conf_id passjJrains( ) did) 
20 drain"! ^^^r ( conf.id pass.drainsj | reject Jrains( ] did ) 

flow (did) 
end^rules 

# 

25 # This is a list of all of the drain identifiers (did's) that are valid In this file. 

# There may be only one drainjist( 1 entry in the file. 
# 

drainjlst[ 12345] 

|...Passffai!--- DELIVER 

MAIL 

I Pass --- KEYWORD FILTER - 1 

35 |.--FBfl -DELIVER 

MAIL 

SIZE FILTER P»» 

\ 

40 |.-. Fail "-BINARY FILTER |---Fail .AUDITMSG 

# This is the starting drain id, the size filter, 
flow (1) 

45 drainjlter(size pass_drains[2] rejed_drains[4l 1) 

drainjlter( keyword passjrainspi reject Jrains(3 5] 2) 
drainlterminal ( "Deliver Mar 3 ) 
drainjlter( binary passjrains(2] reject JrainsfS) 4) 
drain'tenninal ( "Audit Message* 5 ) 



50 



Ffltcr flow modules should be as simple as passible. New or less 
technical users should be able to use the filters in a simple feshion and not be 
overwhelmed by too may options or too much sophistication. When there is a 
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compUcated capabiUty in the system, it may be appropriate to provide a simpler 
version which is easier to use. For example, the key W search filter is based 
on regular expressions, but regular expressions are too intimidatrng to the 
uninitiated and more complex than what many need. So. the key word search 

5 only makes a subset of the functionality visible: tokens with optional wUdcards 
at the beginning and end. For those who want to work with full regular 
expressions, that functionality can be provided in a logically, if not physically, 
separate filter which the less technical users can totally ignore. 

Whenever possible, filters should have a pcr-message threshold 

10 rather than having a boolean aU^r-nothing rejection criteria. For a key word or 
regular text filter this might be a given number of matches. For something like a 
binary filter this might be a certain sensitivity. Obviously, filters s-uch as PGP 
signature verification wiU have a strict boolean behavior. 

If a filter rejects a message, it must attach two kinds of audit 

15 messages to the edo. Tbcse should be attached m order of smaUest to largest 
because, if memory is depleted in processing, the smaUer message can be used in 
place of the large, while the reverse is not always true. Examples of these 
messages include the following. 

1. A brief audit message. 
20 This a short, descriptive message which should describe the failure as 

weU as possible, but be concise enough to be included in an audit record 
In one embodiment the brief audit message is preferably less than 160 
bytes. 

25 2. A detailed audit message. „ . ^ 

This is a detailed message that tries to explain specificaUy why the 

message was lejected. For example, a key word filter would Ust the 
words lhai matched entries in the word list, 

30 3. A generic audit message. , „ . • t 

In one embodiment this is a message that is the same for all rejections. In 
another embodiment this message is configurable, so that the site can 
include inforaiation about the site security poUcy and how to contact the 
responsible administratois for assistance with the violation, fa a fiirther 

3 5 embodiment a generic reason module is created which can be used m 

conjunction with any filter. 
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A variety of filter types are configurable in the mail structure of 
the present invention. One type is a key word search filter, which in its simplest 
form scans the message for a match on any of the words included in a predefined 
list. Another type of filter is a binary filter, which is intended to catch mail 
S which is not 'normal' text or includes nontext attachments. This is a nebulous 
pattern-recognition task. Things that should be caught include MIME 
attachments, uuencoded files, btoa encoded files, binhex encoded files, as well as 
raw binary, encrypted mail and shar files. Normal electronic mail written in 
natural human language such as English should pass. 
10 A third type of filter is a size filter. It is desirable to have a filter 

that rejects messages based on the message size. The threshold (T) would be 
configurable and specified in bytes. The message would be rejected if the 
message size (M) was greater than or equal to the size threshold: 

i^>T (1) 

In one embodiment the threshold is somewhat fiizzy. Where the fuzziness 
1 5 feature is implemented it will be a configurable value (F) in bytes. Given a 
random value (R) uniformly distributed between zero and one, the threshold 
Auction would be: 



M>T^F*liR-~) (2) 
2 

If the overhead of filtering is deemed to be excessive, a filter could be 
20 constructed which applies filters to randomly selected messages. The frequency 
of filtering could be selected as a tradeoffbctween throughput and completeness 
of coverage. This would simply have a single configurable value which would 
be the percentage of messages that would be filtered. Those skillecHn the art 
will recognize there are a wide variety of filter techniques which may be 
25 incoqjoraled without exceeding the scope and spirit of the present invention. 
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Modifiers are map objects that take a single input aiid yield a 
single output Modifiers arc used for actions that do not select the routing of.the 
message, such as adding attachments or some sort of uniform modification of the 
message. An example of the first would be adding a generic rejection reason. 
5 An example of the second would be sanitiang the message headers. 

For one implementation of a key word search filter the intent was 
to have a configurable "generic " rejection reason that would be the same for all 
messages that violated the filter. There are three problems with this approach. 
First, the rejection reason will always be added, even if it is never used, which is 
10 undesirable overhead, especially iffiltere are being chained. Second, from an 
engineering perspective, all filters will need to have the code to support this 
capabiUty built into them- Third, from the user perspective this approach 
provides no simple way to have a single generic rejection reason shared by 
multiple filters. 

J 5 As a result, filters consmicted as part ofthe mail frameworic of 

the present invention will not attach generic rejection reasons to messages. 
Instead, a simple one-in. one-out data modifier will be created which attaches a 
. generic rejection reason to aU messages that flow through. Functionality 
equivalent to the prior design is illustrated in Figure 18 . An alternative use is 

20 illustrated in Figure 19. 

The configuration infomiation for the generic rejection reason 
modifier 1 830 is simply the text ofthe rejection reason. The text is kept in a 
simple ASCn file v(diichwai be attached verbatim to the message. Since no 
other infonnation is configurable, the system configuration file format is not 

25 used. The filter.conf file's confjnfo entries wiU include the path to the file, but 
the token field is not used. For example: 
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ModifieifGenericRejedReason] 



drainjst|did1 did21 

5 conf.modifier { GenertcRcjectReason 

confJnfe(/elc/fiher/generkLreason/policy.lexl didi) generic.rejed.t ) 

conL(nodifier(GenericRejedReason 

conf>fo{ /etc/filtar/generic_reason/caII,admin.text dld2) g€neric_reiecL2 ) 
10 Note that utUity functions should probably be added to the filter library to 

support opening and reading text files with the same file locking semantics used 
by the configuration library so that deadlock and race conditions will be avoided. 

Another function which may be provided through a modifier is to 
sanitize the message headers, Sanitiadng the message headers means to remove 
1 5 information fiom the headers that potentially discloses information about the 
internal network v^iiich is not required by the mail delivery system to deliver the 
mail. Initially, this involve removing the Received-by lines on out-bound mail. 
Many other modifiers are also possible, such as ones that apply digital signatures 
or encrypt messages based on the destination address. The examples given in the 
20 discussion of the modifiers' fimctionality arc offered for illustration and not 
intended to be exclusive or limiting. 

Temiina] objects C'drains") are generally single and may not be 
dynamically configurable. The discussion following details various types of 
terminals and their configuration information. Most identifiers and token names 
25 can be adjusted to suit the needs of the user interface. The examples are' offered 
as illustrations and are not intended to be exclusive or limitmg in any way. 

One type is the 'deliver to recipient' temiina]. This action is to 
deliver the message on to the senders intended recipients. This terminal is 
normally placed at the end of a filter chain as the action for messages that pass 
30 all of the filters. It may be used on failed messages as well, if the site policy 
favors rapid delivery over highly accurate prevention. There are dij^ configurable 
options for this terminal. A single entry will be preconfigured in the 
configuration file filter.conf: 
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Teiminaipeliverl 

conf Jerminal ( Deliver conLinfo (none none ) 'Deliver Mail" ) 

The "return lo sender" teiminal returns the message to the sender. 
5 The rejected message can include the detailed rejection reason, the generic 
rejection reason, or the brief rejection reason. If the filter is configured to return 
the generic reason, but one has not been attached, it wiU use the brief rejection 
reason instead. The only configurable option is the type of rejection message. 
This information wUl be included in the token field of the configuration 
10 information. These entries will not have separate configuration files. In the 
embodiment where there are only three possible configurations, all three should 
be preconfigured in the default installation. 

terminal[RetumToSender] 
1 5 conf.terminal ( RetumToSender eonfjnfa ( none brief ) "Return w/brief ) 

conf.terminal ( RetumToSender confjnfo ( none generic ) "Return w/generic" ) 
conf.temiinal ( RetumToSender confjnfo ( none detailed ) "Refum w/detaib" ) 

The "mail to reviewer^ temiinal encapsulates the message and 
20 sends it on to an auditor. The message must be encapsulated as cither a MIME 
attachment or simply an indented block of text In one embodiment, this choice 
is configurable. In an alternate embodiment, the choice is not configurable, and 
is preconfigured to support a single delineation (such as an indented text block). 
It is important that the message be encapsulated in some manner so that common 
25 program mailer attacks are ineffectual when the message is sent to the reviewer. 
Otherwise, one could construct a filter that detects the attack and forwards it on 
to attack the auditor. This is a convenient method to get information to the 
auditor, but mail forwarded in this feshion cannot be properly forwarded on by 
the reviewer. If sending is dependent upon the reviewer, then the reviewer will 
30 need to use a manual review tool. The configurable options of this terminal arc 
the e-mail address of the recipient of the message, the burb name of where the 
electronic mail address is. the choice of rejection message to include (if any) and 
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whether or not to include the message or just the rejection message. A single 
configuration file will exist to contain the configuration infomation for all 
terminals of this type. The infonnation in configMo will be the path to the 
configuration fiile and the terminal identifier. For example: 

Tefmina![MairToReviewerl 

conf_temunal ( MaifToReviewer confjnfb { /etc/filter/mailaudlLconf Charlie ) "Charlie*' ) 
confjemiinal ( MallToReviewer confjnfo ( /etcmiter/mailauditconf Linus) "Unus*') 
conLterminal ( MairtoReviewer confjnfb { /etcffllter/mailauditconf Lucy ) "Lucy^ ) 

One example of the contents of the corresponding mail audit configuration file 
(mailauditxonf) is illustrated in the following example. 
Mail Audit Configuration File 

15 begin rules 

# 

# conf id: must match the confjnfb ( token ) field in filter.conf 

# auditllevel: one of "none". "brierT-generic" or ■detailed" 

# include^n^g: cither 'Ves" or 'no" 

20 # address: the e-mail address to which mail should be sent 

# burfo: the burb where the reviewers &-mafl address is locate 
d 

# de^ultis: trusted 



10 



25 



# 

mailaudit(conf_id audil.level Include^msg address burb) 
end rules 



mailaudit ( Charlie detailed yes chartie@ldte.com internal ) 
30 mailaudit (Linus generic no lv@blanlceLorg external) 

mailaiidit ( Lucy brief yes expert@nfclcel.psychiatrist.com internal ) 

Mail messages may be very large, especially for a binary filter or 
a message size filter. The log to file" terminal logs messages to a file in a 

35 directory. The directory is coifigurablc. There will be a single instance of one 
such directoiy prcconfigured on the system. When configuring a new instance, 
the directory will need to be created, typed, and added to the feciJity that rolls 
over audit and log files. If there is a manual review tool it will be gle to process 
messages from this directory. This could be used in a manner analogous to 

40 strikeback reports, mail a simple notice, and store the whole thing in a file. The 
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mail notificr described previously would be used in this scenario to send a brief 
or generic rejection notice. The configurable options include the directory to use 
when writing out the message, the choice of rejection message to include (if any) 
and whether or not to include the message or just the rejection message. A 
5 single configuration file will exist to contain the configuration information for all 
teraiinals of this type. Two entries will be prcconfigured; one for each of the 
standard flows. The information in config^info will be the path to the 
configuration file and the terminal identifier. For example: 

10 TerminallLogToFile] 

conf.temiinal { LogToFite confjnfo ( /etc/fftter/fileaudiLconf intext ) intext ) 
conrterminal ( LogToFile confjnfo ( yetcffilter/fileaudftconf artint ) extint ) 

An example of the contents of the conrcsponding file audit configuration file is 
1 S shown in the following example. 
Mail Audit Configuration File 

begin^mles 
# 

20 # conf^id: must match the confjnfo ( token ) field in filter.conf 

# audiT level: one of "none", "brier, "generic" or "detailed" 
#indude„msg: either "yes" or "no" 

# directory: directory where message files will be written 

25 fileaudit ( conf Jd audit Jevel Indude.msg directory) 

end mies 
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fileaudit ( intext detailed yes /var/spool/filelog/intext ) 
fileaudit ( extint generic no /var/spool/filelog/extint ) 

Another terminal type is the ''audit" terminal. This terminal sends a 
message to the audit device. This will be of a type specific to filtermg and will include 
the source burb, destination burb and the brief audit message. Nothing is configurable 
in this teraiinal. A single entry will be prcconfigured in filter, conf. 

TemiinaI[Auditl 

conf jerminal ( Audit confjnfo ( none none ) "Audit Message" ) 



The terminal examples described above arc exemplary only and not intended to 
40 be exclusive or limiting. Those skilled in the art will recognize that other 

terminal types may be constructed without exceeding the spirit and scope of the 
present invention. 
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AWjough the present inventioa has been described with reference 
10 the prcfeircd embodiments, those skilled in the art will recognize that changes 
may be made in form and detaU without departing from the spirit and scope of 
the invention. 
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APPENDIX I 



Filter Configuration File Example 

5 # 

# Description: Configures the terminals, modifiers and fitters for mail filtering. 

# what is configurable: 
# 

10 # confJnfo{path token): 

# Configuration information for terminals, modifiers and filters are all specified in 
the same way 

tt using conf the info rule. This rule includes a path to a configuration file and a 
15 token. For^^^^ ^^^^ ^ suffidenL For others, the file may include 

everything ^ ,he toKen may not be used, if multiple items share a configuration file, then 
20 # ^ '"^ "S'specified by the path and the token may indicate a specific entn^ in the file. If 

a token or^^ _^ unused rt must be set to the string "none". This means that "none" 

cannot be 

« used as a valid value for either of these fields. 
25 # 

# confjerminal ( terminal conf_infb{ ) conf_id ): 

# A configured terminal is given with the confjerminal rule. This associates an 
30 # ^"''''^'th^emiinal type and this set of configuration informaUon. For many there wil 

T "° configurables. so they may be preconfigured and the user wiB not be able to 

"""^"^additional ones. The terminal field must contain a valid field from the Terminal[ 1 
35 list 

# corif_modifi6r ( modifier conf Jnfo( ) conf_id ) 

I A configured modifier is given with the conf_modifier mla. This associates an 

40 identifier with the ^ tu «».^r.oM muct 

» modifier type and this set of configurahon information. The modrfier field must 

contain a valid field 

# from the Modifier^ j list 

45 conf_filter I filter confJnfo( ) conf jd ) 

# A configured filter is given with the conf_filter njle. This associates an identifier 

7^ filter type and this set of configuration information. The filter fiejd must contain a 

50 valid field 

# from the Filter! 1 ''s*- 

^jiuii))jiii,)j fififdKfff 'iii'ii'liiTffiriTiTiTiT" nnnnnnmn 

55 » 



JNSOOCIO: <GB 23t7793A \ > 



31 



# Examples: 

# FILTERS: 

# Configunng a key word search filter 

5 # conf Jlter( Key Word confjnfo (/etc/filter/kws/kws.conf none) keyword) 
# 

4 Configuring a size filter 

# confJHer( Size confjnfo (/etc/fiiter/size/size.conf size) size) 
# 

10 # Configuring a binary filter 

# conf Jller( Binary confjnfo /etc/fflter/binary/binary.conf binary) binary) 
# 

# Modifiers: 

# Configuring a generic rejection reason modifier 

1 5 # conf_modifier( GenericRejedionRaason" confjnfo( 

/etc/filter/generic_reason/generic.file none) 9eneric_Modifier) 

# 

#TERIWINALS: 

# Configuring the log to file terminal: 

20 # conf Jerminal( "LogToFlie" confJnfb(/etc/filter/fileaudiLconf intext) log_to_file) 

# " 

# Configuring the mail to reviewer terminal: 

# conf Jerminal( "MaifToReviewer confjnfo(/etc/filter/mailauditconf John) "John 
Smith") 

25 # 

# Configuring the audit file temiinal: 

# conf terminal ("AudiT conf mfb(none none) audit^msg) # 

mnmMmmiimimnmmuHmmmmmmmmsmimm 

30 

l)egin_rules 

conf Jnfo(path token) 

conf jarminal ( terminal confJnfb{) confjd) 
conflmodifier ( nrwdifier confjnfo confjd) 
35 confjiter ( filter conf^info conf_id) 

end_rules 

# list of temiinal module types. There may only l>e one such fist 
# 

Terminal ( "MairToReviewer "LogToFile" "Audif "Deliver** "RetumToSerKier J 
# 

# list of modifier nrwdule types. There may only be one such list 
# 

Modifier ( "GenericRejectionReasan" ] 
# 

# list of filter module types. There may only be one such list 
50 # 

Filter rSize" "KeyWord" 'Binary" ) 

# Configuring the return to sender terminal: 

confjerminal ( ReturnToSender confjnfo(none brieO "Return w/brief ) 
55 conf_terminal ( ReturnToSender conf info(none generic) "Return w/generic* ) 
conf Jemiinal ( ReturnToSender confjnfo(none detailed) "Return w/details" ) 
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# Configuring the deliver to recipients terminal: 
conMerminal { Deliver conf Jnfo(none none) "DeUver Mail" ) 

# Configuring the audit terminal: 

5 conMerminal ( Audit confjnfo ( none none ) "Audit Message** ) 

© 1996 Secure Computing Corporalion 



WSCXXIO: <GB„ ,.2317793A_ll> 



33 



CLAIMS 

1 A method of filtering electronic mail message, comprisiag the steps of: 

defining a plurality of node, herein each node identifies an operauon 

ar.d .vherein one of the nodes is a filter node v,hich identifies messages to filter; 

5 interconnecting nodes ftom the plurality of nodes such thai the 

interconnected nodes describe a security policy; and 

passing an electronic maU message throughthe filter node, ^«herem the 

stepofpassinganelectronic mail message throughd^filter node indudcsthe 

Steps of: ^. . - V 

10 determining if the electronic maU message is one which ts to be 

filtered; 

if the electronic mail message is identified as to be filtered, 
processing the elecuonic mail message through one or more filter flows; 

otherwise delivering the electronic mail message without filtering. 



and 



15 



2. The method of claim 1. v*erein the step of processing the electronic mail 

message comprises the steps of: 

analyzing the message to determine if it has a particular characteristic; 

20 and 

disposing of the electronic mail message based on the ou.«.me of the 

analysis. 

3. method of claim 2. wherein the step of disposing of the electronic 
25 mail message comprises the step of delivering the message. 

4. nte method of claim 2. wherein the step of disposing of the electronic 
mailmessagecomprisesthestepofrejectingthemessage. 

30 5. Themethodofclaim2.whereinthestepofdisposingoftheelecironic 
mail message comprises the step of tnm.smitiing an audit message. 
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6. The method of claim 3. wherein the step of disposing of the electronic 
mail message comprises the steps of: 

delivering the message; 
rejecting the message; and 
5 transmitting an audit message. 

7. The method of claim 1. wherein the step of disposing of the electronic 
mail message comprises the step of modifying the first electronic mail message. 

10 8, The method of claim 7, wherein the step of disposing of the electronic 
mail message comprises the step of altering the first electronic mail message 
address. 

9. The method of claim 7, wherein the step of disposing of the electronic 
1 5 mail message comprises the step of altering the first electronic mail message 

header. 

10. An electronic mail filter, comprising: 

an analysis module for anal)^ electronic mail message, wherein the 

20 analysis module includes: 

node defining means for defining a plurality of nodes, v/herein 

each node identifies an operation and wherein one of the .nodes is a filter 
node which identifies messages to filter; and 

interconnecting means for interconnecting nodes from the 
25 plurality of nodes such that the interconnected nodes describe a security 

policy; and 

an output module, connected to the analysis module, for generating a 
plurality of output messages, wherein one of the plurality of mcr sages is 
generated as a fimction of analysis of the electronic mail message by the analysis 
30 module. 
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11. The electronic mail filter of claim 10. wherein the node defining means 
includes means for creating a plurality of individual independent fUter, modifier 

and tcnninal nodes; and 

wherein the interconnecting means includes means for interconnecting 
5 the pluiality of individual filter, modifier and terminal nodes. 

12. A system for filtering electronic mail, comprising: 

means for receiving electronic mail messages, mcluding a fet message. 

firom one or more sources; and 
10 an analysis module for determining whether to filter the first message. 

wherein the analysis module includes: 

a plurality of filters, including a first filter, for analyzing 
characteristics of the first message; and 

one or mote terminals, including a first terminal, for deUveiing 
15 the first message to one ormoie destinations. 

13. The system of claim 12. wherein the analysis module fiiither comprises a 
plurality of modifiers, including a first modifier, wheremeach of the pluraUty of 
modifiers operates to modify the first message. 

20 

14. A method of managing a filter map. comprising the steps: 
identifying one or more nodes to be included in the map, wherein each 

node defines an operation to be performed on a message, wherein the step of 
identifying includes the step of defining a security policy; 
25 defining an order in which operations arc to be pcrfomed on the message; 

graphically positioning each of the one or more nodes according to the 

defined order; and 

graphically identifying connections between the nodes.'u a fimction of 
one or more routing paths available fiom any one node. 

30 
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15. A method for constructing an electronic mail filter having one or more 
message routing paths, comprising the steps: 

identifying a poUcy describing the one or more message routing 

paths; 

defining a plurality of filter nodes for analyzing electronic mail 
messages; 

defining a plurality of modifier nodes for modifying electronic 
mail messages; 

defining one or more terminal nodes for delivering electronic mail 
messages and other electronic information; and 

interconnecting the pluraUty of filter nodes, modifier nodes and 
terminal nodes so as to implement the policy. 

1 6. An electronic mail system, comprising: 

a mail filter (220) having a plurality of filter objects (802, 803. 804). 
wherein the filter objects arc axxanged in a flow which enforces a security policy; 
and 

aj 

mail delivery agent receives an electronic mail message and routes the electronic 
mail message based on a mail filter policy, wherein the maU filter poUcy 
determines mail to queue and mail to pass on; 

wherein the mail filter retrieves electronic mail messages queued by the 
mail delivery agent and filters the retrieved electronic messages according to the 
security policy. 

17. The electronic mail system according to claim 16. wherein the plurality 
of filter objects includes a terminal node type (802). 

18. The electronic mail system according to claim 1 6. wherein the plurality 
of filter objects includes a modifier node type (803). 



. mail deUvery agent (210) comiected to the mail filter (220). wherein the 
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1 9. The electronic mail system according to claim 1 6, wherein the plurality 
of filter objects includes a filter node type (804). 

20. The electronic mail system according to claim 1 6, wherein the plurality 
5 of filter objects includes a plurality of node types (802. 803 , 804), wherein each 

node type includes an initialization section, a message processing section and a 
node clean-up section. 

21. Tlic electronic mail system according to claim 16. wherein the plurality 
10 of filter objects includes a plurality of node types (802. 803. 804), wherein one of 

the plurality of node types appends infonnadon on to a mail message. 

22. The electronic mail system according to claim 16, wherein the plurality 
of filler objects includes a plurality of node types (802, 803, 804). wherein one of 

1 5 the plurality of node types generates audit messages. 

23. The electronic mail system according to claim 16 or 20, wherein the mail 
filter policy is stored in a mail filler policy file as a set of buib pairs, wherein 
each burb pair includes a first and a second burb, wherein messages from the 

20 first to the second burb are queued by the mail delivery agent. 

24. A method of filtering electronic mail messages, comprising the steps of: 
providing a plurality of node types; 

connecting the plurality of node types according to a secmity policy; 
25 receiving an electronic mail message; and 

analyzing the electronic mail message as a fimction of the electronic mail 
message. 

25. The method according to claim 24. wherein the step of connecting 
30 includes the steps of: 

displaying the plurality of node types as icons within a visual medium; 
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placing copies of the icons on the visual medium in rcspoa^e to input 

from a user; and 

connecting the icons placed on the visual medium. 

26. The method according to claim 24. wherein the step of connecting 
includes the step of configuring the plurality of nodes types to perform a 
function from one of a set of functions including forwarding, rejecting and 

returning the message. 



Amendments to the claims have been filed as fqlows 



CLAIMS 

S i,„rco,m«tmg,»<l«t»th.pte.lin'of»>*»»cbtolh= 
in,.rco».«=tcd«od=decnl«.!e«il,ponc)r,»»l 

filtered; 

•1 ^^cc^o^ U Identified as to be nltered, 
if the electronic mail message is laenuucu 

and 

, 5 otherwise delivering the clcctrooic mail message without filtenng. 

2. The method of claim I. whe«in the step of processing the electronic mail 

message comprises the Steps of: 

analyzing themessageto determine if ithasaparticularcharactei^^^ 

20 and ^..v,^ 
disposing of the electronic mail message based on the outcome of the 

analysis. 

3 The method of claim 2. wherein the step of disposing of the electronic 
25 mail message comprises the step of delivering the message. 

4. Themethodofclaim2.whcreinthestepofdisposingoftheelectronic 
mail message comprises the step of rejecting the message. 
30 5. ThemethodofclaimLwhereinthestepofdisposingoftheelectronic 
mail message comprises the step of transmitdng an audit message. 
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6. The method of claim 3. wherein the step of disposing of the electroxuc 
mail message comprises the steps of: 

delivering the message; 

rejecting the message; and 
5 transmitting an audit message. 

7 The method of claim 1. wherein the step of disposing of the electronic 
mail message compri^s the step of modifying the first electronic mail message. 

10 8 "n,e method of claim 7. whereinthe step of disposing of the electronic 
n,ail message comprises the step of altering the first electronic mail message 
address. 

9 The method of claim 7. wherein the step of disposing of the electronic 
:uail message comprises the step of altering the first electronic mail message 
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header. 



1 0 An electronic mail filter, comprising: 

an analysis module for analyzing an electrode mail message, wherein the 

20 analysis module includes: 

node defining means for defining a pluraUty of nodes, wherem 
each node identifies an operation and wherein one of the rtodes is a filter 
node which identifies messages to filter, and 

intercomiecting means for interconnecting nodes from the 
plurality of nodes such that the interconneaed nodes describe a security 
policy; and 

an output module, connected to the analysis module, for generating a 
plurality of output messages, wherein one of the plurality of mj^sages is 
generated as a function of analysis of tiie electronic message by the analysis 
30 module. 
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1 1 . The electronic mail filter of claim 10, wherein the aode defining means 
includes means for creating a plurality of individual independent filter, modifier 
and terminal nodes; and 

wherein the interconnecting means includes means for interconnecting 
5 the plurality of individual filter, modifier and terminal nodes. 

12. A system for filtering electronic mail, comprising: 
means for receiving electronic mail messages, including a first message, 

firom one or more sources; and 
10 an analysis module for determining whether to filter the first message, 

wherein the analysis module includes a plurality of nodes, wherein the nodes are 
interconnected to enforce a security policy and wherein the plurality of nodes 
include: 

a plurality of filter nodes, including a first filter node, for 
1 5 analyzing characteristics of the first message; and 

one or more terminal nodes, including a first terminal node, for 
delivering the first message to one or more destinations. 

13. The system of claim 12, wherein the plurality of nodes further include a 
20 plurality of modifier nodes, including a first modifier node, wherein each of the 

plurality of modifier nodes operates to modify one or more electronic mail 
message and wherein the first modifier node operates to modify the first 
message. 

1 4. A method of managing a filter map. comprising the steps: 
identifying one or more nodes to be included in the map, v4icrein each 

node defines an operation to be pcrfonned on a message, wherein the step of 
identifying includes the step of defining a security polx^; 

defining an order in viiich operations are to be pcrforaied on the 
message; 

graphically positioning each of the one or more nodes according to the 
defined order; and 

graphically identifying connections between the nodes as a function of 
one or more routing paths available from any one node. 
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^2. 

,5. A method for constnicting an electronic mail filter having one or more 
message routing paths, comprising the steps: 

identifying a policy describing the one or more message routing 

paths; 

5 defming a plurality of filter nodes for analyzing electronic mail 

messages; 

defining a plurality of modifier nodes for modifying electronic 
mail messages; 

defining one or more terminal nodes for delivering electronic maU 
10 nicssages and other electronic information; and 

intercomiccting the plurality of filter nodes, modifier nodes and 
terminal nodes so as to implement the policy. 

16. An electronic mail system, comprising: 
15 a mail filter (220) having a pluiaUty of filter objects (802. 803. 804). 

wherein the filter objects are arranged in a flow which enforces a security policy; 
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and . 

a maU deUvery agent (210) connected to the mail filter (220). wherem the 

mail delivery agent receives an electronic mail message and routes the electromc 
20 mail message based on a mail filter poUcy. wherein the mail filter poUcy - 
determines maU to queue and mail to pass on; 

wherein the mail filter retrieves electronic mail messages queued by the 
xnaU delivery agent and filters the retrieved electronic messages according to the 



security policy. 

17. The electronic mail system according to claim 16. wherein the plurality 
of filter objects includes a terminal node type (802). 

18. The electromc mail system according to claim 16. wherein the plurality 
30 of filter objects includes a modifier node type (803). 
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1 9. The electronic mail system according to claim 1 6, wherein the plurality 
of filter objects includes a filler node type (804). 

20. The electronic mail system according to claim 16, wherein the plurality 
5 of filter objects includes a plurality of node types (802. 803 . 804). wherein each 

node type includes an initialization section, a message processing :jection and a 
node clean-up section. 

21. The electronic mail system according to claim 1 6, wherein the plurality 
10 of filter objects includes a plurality of node types (802, 803. 804), wherein one of 

the plurality of node types appends inforaiation on to a mail message. 

22. The electronic mail system according to claim 16, wherem the plurality 
of filler objects includes a plurality of node types (802, 803, 804), wherein one of 

1 5 the plurality of node types generates audit messages. 

23. The electronic mail system according to claim 16 or 20, wherein the mail 
filter policy is stored in a mail filter policy file as a set of burb pairs, wherein 
each burb pair includes a first and a second burb, wherein messages from the 

20 first to the second burb are queued by the mail delivery agent. 

24. A method of filtering electronic mail messages, comprising the steps of: 
providing a plurality of node types; 

connecting the plurality of node types according to a secujity policy; 
25 receiving an electronic mail message; and 

analyzing the electronic mail message as a function of the electronic mail 
message. 

25. The method according to claim 24. wherein the step of connecting 
30 includes the steps of: 

displaying the plurality of node types as icons within a visual medium; 
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placing copies of the icons on the visual medium in respoase to input 

from a user; and 

connecting the icons placed on the visual medium. 



26. The method according to claim 24, wherein the step of connecting 
includes the step of configuring the pltirality of nodes types to perform a 
function from one of a set of fiinctions including forwarding, rejecting and 
returning the message. 
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